Many organizations are embracing the paradigm of Model Based Development in their production processes. “Model Based Development” refers to the practice of specifying, analyzing, and implementing systems using a common “model” consisting of a set of block diagrams and associated objects. System implementation typically consists of automatically generating code for portions of the model, particularly portions corresponding to the system's control algorithm.
Graphical modeling environments are an example of software applications that may enable a user to model, simulate, and analyze dynamic systems i.e., systems whose outputs change over time, using a graphical model, such as a block diagram. Simulating a dynamic system in a graphical modeling environment is typically a two-step process. First, a user creates a graphical model, such as a block diagram, of the system to be simulated. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts time-based relationships between the systems inputs, states, parameters and outputs. After creation of the graphical model, the behavior of the dynamic system over a specified time period is simulated using the information entered into the graphical model. In this step, the graphical model is used to compute and trace the temporal evolution of the dynamic systems' outputs (“execute the graphical model”), and automatically produce either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of the model (code generation).
Block diagrams are graphical entities having an “executable meaning” that are created within graphical modeling environments for modeling a dynamic system, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system is represented schematically as a first collection of graphical objects, such as nodes, which are interconnected by another set of graphical objects, generally illustrated as lines, which represent logical connections between the first collection of graphical objects. In most block diagramming paradigms, the nodes are referred to as “blocks” and drawn using some form of geometric object (e.g., circle, rectangle, etc.). The line segments are often referred to as “signals”. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition of the relationship between the signals and the state variables is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a port. The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination nodes of this signal read from the signal when their system equations are being solved. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
Automatic code generation is a process whereby software source code is automatically produced from a model of a system, such as a block diagram. For example, in some environments, automatic code generators transform hierarchical block diagrams into software. The software source code produced by the automatic code generation process may be compiled and then executed on a digital computer, implementing the functionality specified by the model. The hierarchy of the model maps to the functional call graph of the generated code. It is desirable for users of automatic code generators to control the signatures of the produced functions in the generated code.
It is often the case that the implementation of a model, i.e., the code generated, is affected by settings associated with the objects and components of the model. For example, one might configure settings of some objects to affect data declarations and definitions. Another setting might exercise a time-space tradeoff in the generated code. These settings are typically chosen and exercised through graphical user interfaces provided within the graphical modeling environment. Another collection of component settings might affect the form of the function signatures created.
A drawback to current systems is that the affect of the settings on the code generated for the model is not immediately obvious to the users from the model. For example, the necessary arguments to the functions are generally not immediately obvious to the user from the model. Typically, many arguments are artifacts resulting from implementing an object-oriented design specification (e.g. functional units with internal states) with a procedural language (e.g. C or Ada). For example, many arguments are unexpected because the arguments do not map directly to the input and output ports of the subsystem or model to which the function corresponds. Another drawback in current environments is that it can be cumbersome to maintain a literal specification of the function signatures as elements of the model are added and deleted, which changes the exact number and types of function arguments.
In addition, generation of code for a model can consume significant time, and it is not always possible to generate code for a partially specified model. Therefore, if a tool user wishes to observe the impact of the settings chosen through inspection of the generated code, it is often necessary to construct and generate code for the entire model. Then, the user can review the generated code, change one or more of the settings if the impact is not what is desired, and generate the code again for the entire modified model. Such a process is time-consuming, inefficient and at times impossible.